The following abbreviations are herewith defined, at least some of which are referred to within the ensuing description of the prior art and the present invention.    3GPP Third Generation Partnership Project    AS Application Server    CSCF Call Session Control Function    DNS Domain Name System    HSS Home Subscriber Server    IAM Initial Address Message    IBCF Interworking Border Control Function    I-CSCF Interrogating CSCF    IMS IP Multimedia Subsystem    IP Internet Protocol    MGCF Media Gateway Control Function    MMS Multimedia Messaging Service    POTS Plain Old Telephone Service    PSTN Public Switched Telephone Network    PUI Public User Identity    RFC Request For Comments    RTP Real-Time Transport Protocol    S-CSCF Serving CSCF    SIP Session Initiation Protocol    SLF Subscription Locator Function    TCP Transmission Control Protocol    UA User Agent    UE User Equipment    URI Uniform Resource Identifier    UTM URI Translation Module
An IMS network is an IP-based network that enables User Agents (UAs) of an IMS network, as well as User Equipments (UEs) of other legacy networks, to establish multi-media sessions to other UAs so they can exchange any kind of real-time information (e.g. voice, video) or non-real-time information (e.g. messages, pictures). In its current state, the IMS network uses a SIP protocol to establish the multi-media sessions and a transport protocol like e.g. RTP to carry the payload of the multi-media sessions.
In the IMS network, the information is routed on a multi-media session that was established with the target user by using an URI that identifies that user and by using a set of well-defined routing rules that must be followed by all of the elements within the IMS network. This set of rules is defined for 3GPP-compliant IMS networks in 3GPP TS 24.229 V.5.14.0 (October 2005) which is entitled “IP Multimedia Call Control Protocol Based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)” (the contents of which are incorporated by reference herein).
There are two types of URIs that can be used to identify a particular target user when establishing a multi-media session: (1) SIP URIs; and (2) tel URIs. A SIP URI has a format that is defined in RFC3261 which is entitled “SIP: Session Initiation Protocol” June 2002 (the contents of which are incorporated by reference herein). Examples of SIP URIs are:                sip:peter@yahoo.com        sip:James.Rowling@RowlingAndAssociates.co.uk        sip:voice_mail@vodafone.com;reason=no_answer        
While, the format of a tel URI is defined in RFC3966 which is entitled “The tel URI for Telephone Numbers” (the contents of which are incorporated by reference herein). Examples of tel URIs are:                tel:+1-234-567-89        tel:2997;phone-context=+3491339        
In addition, there is a way to express a SIP URI with an embedded tel URI which is discussed in RFC3261. For instance, the exemplary tel-URIs could be embedded within SIP URIs as follows:                sip:+1-234-567-89@cingular.com;user=phone        sip:2997;phone-context=+3491339@vodafone.com;user=phone        
A section of the set of routing rules mentioned above is devoted to routing calls between two different network operators. Specifically, when routing a call between two network operators a SIP URI or SIP URI/embedded tel URI must be used to identify the target user for the call. FIG. 1 (PRIOR ART) is a signal flow diagram used to help describe a first routing process, namely the inter-operator process of using a SIP URI/embedded tel URI to route a call from a UA1 located in an originating network 102 to a UA2 located in a terminating/destination network 104. The steps are as follows (reference is made to 3GPP TS 24.229 for more details):    1-3. The originating S-CSCF1 receives a SIP request (e.g., INIVITE tel: +123) from UA1 (step 1). The S-CSCF1 takes a Request-URI from the received session-initiating INVITE request and if the Request-URI contains a tel URI then S-CSCF1 queries an ENUM1 service (step 2). The ENUM1 changes the tel URI into a SIP URI/embedded tel URI (e.g., sip: +123@op.com;user=phone) and sends it to the S-CSCF1 (step 3). The S-CSCF1 replaces the original Request-URI in the SIP request with the SIP URI/embedded tel URI obtained from the query to form a new SIP request (e.g., INVITE sip: +123@op.com;user=phone).    4. The originating S-CSCF1 takes the domain part (e.g., op.com) of the new Request-URI and forwards the new INVITE SIP request to the address identified by that domain (if the domain is an IPv4 or IPv6 address the INVITE can be forwarded to that address straight away, otherwise a DNS needs to be queried using the domain part to obtain a destination IP address, which corresponds to either an IBCF or an I-CSCF2 in the terminating network 104). In this example, the S-CSCF1 forwards the new SIP request (e.g., INVITE sip: +123@op.com;user=phone) directly to the I-CSCF2 (step 4).    5-6. The I-CSCF2 is the first CSCF contacted for the terminating call and has the role of locating the S-CSCF2 that is serving the UA2 to which the call is targeted. To locate the S-CSCF2 that serves UA2, the I-CSCF2 may need to use two network databases: (1) the SLF2; and (2) the HSS2. The SLF2 is a database location function that finds the specific HSS2 instance which holds the UA2's subscriber data (including which S-CSCF2 is currently serving them), and is used when there are multiple HSSs instances in the terminating network 104. In this example, the I-CSCF2 uses the Request URI in the SIP request as a public user identity to send a query (e.g., Dx-Location-Query PUI=sip: +123@op.com;user=phone) to the SLF2 (step 5). Then, the SLF2 sends a response (e.g., Dx-Location-Query_Rsp Server-Name=HSS2) which indicates the HSS2 back to the I-CSCF2 (step 6). In the event there is a unique HSS in the network, then the SLF2 and steps 5-6 may be omitted.    7-8. The I-CSCF2 uses the Request URI in the SIP request as a public user identity to send a query (e.g., Cx-Location-Query PUI=sip: +123@op.com;user=phone) to the HSS2 (step 7). Then, the HSS2 sends a response (e.g., Cx-Location-Query_Rsp Server-Name=S-CSCF22) which indicates the S-CSCF2 back to the I-CSCF2 (step 8).    9-10. Once the I-CSCF2 has located the S-CSCF2 it routes the call (e.g., INVITE sip: +123@op.com;user=phone) to that S-CSCF2 (step 9). The terminating S-CSCF2 then uses its internal location table to route the INVITE request to the contact address registered by the target user UA2 (in the example above this contact address is B-UE@op.com) (step 10). If there is no contact address registered, but the target user UA2 has activated some service which has an unregistered state, then the S-CSCF2 forwards the SIP request to the AS indicated by the service information stored within the S-CSCF2.
Referring to FIG. 2 (PRIOR ART), there is a signal flow diagram which is used to help describe a second routing process, namely the routing process that takes place when a call does not come from a peer S-CSCF1 in a remote network 102 as discussed above but instead when it comes from a MGCF1. This particular second routing process occurs when a user UE3 is located in a PSTN 202 and initiates a call with a tel URI towards the UA2 which is located in the IMS terminating network 104. The steps for this particular routing process are as follows (reference is made to 3GPP TS 24.229 for more details):    1a. The MGCF1 has a PSTN signaling interface that receives an IAM sent from UE3 (step 1a). The MGCF1 uses the IAM to obtain the target user's E.164 number and generate an INVITE SIP request that includes a Request-URI field which has either a tel URI (containing the E.164 number) or a SIP URI (with embedded E.164 number).    2a. In this particular example, the INVITE SIP request includes a tel URI (e.g., tel:+123) (compare this step 2a to step 4 in FIG. 1). The MGCF1 forwards the INVITE SIP request (e.g., INVITE tel:+123) to the I-CSCF2 which is located in the terminating network 104 (step 2a).    3a-8a. The steps 3a-8a are similar to steps 5-10 from the previous routing procedure shown in FIG. 1 except that a tel URI (e.g., tel:+123) is used in some of the signals rather than the SIP URI (e.g., sip:+123@op.com;user=phone).
Unfortunately, the routing procedures described above presents some problems:
1. In the first routing process, the target telephone number used to initiate the call is lost before the INVITE SIP request arrives at the terminating network 104. In particular, the target telephone number is removed from the Request-URI within the SIP request by the originating S-CSCF1 when it replaces the originally-dialed tel URI with the SIP URI/embedded tel URI which was obtained from the ENUM1 (see steps 2-3). This is not very desirable because it may be necessary for the terminating network 104 to provide this telephone number to certain services (e.g., MMS).
2. In both routing processes, to internally route a call within the terminating network 104, the user profile within the HSS2 and the user-server association within the SLF2 must include both the tel URI and the SIP form of that tel URI (SIP URI/embedded tel URI). This is needed because there are instances in the routing procedure where the SIP request received at the terminating network 104 can contain either a SIP URI/embedded tel URI (see FIG. 1) or a tel URI (see FIG. 2). Since, it is not known a-priori which format is actually being used by a given originating network 102, to be able to internally route the call within the terminating network 104 the user-server association within the SLF2 and the user profile within the HSS2 needs to include both the tel URI and the SIP form of that tel URI (the SIP URI/embedded tel URI). Thus, the SLF2 and HSS2 each need to maintain duplicate information for both the tel URI and the SIP URI/embedded tel URI which not only increases the administrative burden but also wastes memory space. This is not desirable.
Accordingly, there has been and is a need to address these shortcomings and other shortcomings associated with the prior art. These needs and other needs are satisfied by the present invention.